Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Refactor - JIT noop insertion #584

Merged
merged 3 commits into from
Sep 5, 2024
Merged

Refactor - JIT noop insertion #584

merged 3 commits into from
Sep 5, 2024

Conversation

Lichtso
Copy link

@Lichtso Lichtso commented Sep 4, 2024

No description provided.

@Lichtso Lichtso force-pushed the refactor/jit-noop-insertion branch from 6b58569 to 31173a5 Compare September 4, 2024 06:51
@Lichtso Lichtso force-pushed the refactor/jit-noop-insertion branch from 31173a5 to ef1fe8d Compare September 4, 2024 08:56
@Lichtso Lichtso merged commit de52d05 into main Sep 5, 2024
12 checks passed
@Lichtso Lichtso deleted the refactor/jit-noop-insertion branch September 5, 2024 10:29
@Lichtso Lichtso requested a review from LucasSte September 25, 2024 07:57
@@ -321,6 +325,7 @@ pub struct JitCompiler<'a, C: ContextObject> {
pc: usize,
last_instruction_meter_validation_pc: usize,
next_noop_insertion: u32,
noop_range: Uniform<u32>,
runtime_environment_key: i32,
diversification_rng: SmallRng,

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not related to this PR, but I found out that SmallRng isn't good when security is a concern:

Furthermore, SmallRng is not a good choice when:
Security against prediction is important. Use StdRng instead.

https://docs.rs/rand/latest/rand/rngs/struct.SmallRng.html

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The PRNG here needs to be fast, not high quality. The actual security comes from diversity of seeds in validators across the cluster.

@@ -393,7 +399,7 @@ impl<'a, C: ContextObject> JitCompiler<'a, C> {
self.emit_subroutines();

while self.pc * ebpf::INSN_SIZE < self.program.len() {
if self.offset_in_text_section + MAX_MACHINE_CODE_LENGTH_PER_INSTRUCTION > self.result.text_section.len() {
if self.offset_in_text_section + MAX_MACHINE_CODE_LENGTH_PER_INSTRUCTION * 2 >= self.result.text_section.len() {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this overestimation is too high. We could decrease MAX_MACHINE_CODE_LENGTH_PER_INSTRUCTION to 90. Also, a nop instruction is a single byte. If we emit a maximum of (e.g.) 8 x86 instructions per SBPF instruction, we could do MAX_MACHINE_CODE_LENGTH_PER_INSTRUCTION + 8. In the worst case scenario, there will be one nop per x86 instruction.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is high yes, but it can only run into the end one sBPF instruction earlier. And that should be covered by MAX_EMPTY_PROGRAM_MACHINE_CODE_LENGTH. Generally I would be rather conservative and overestimate here as this is the only bounds-check for the emitted code size.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants